Context modeling for transform coefficient coding

ABSTRACT

A device for coding video data is configured to code a first syntax element, wherein a value for the first syntax element indicates whether there is at least one non-zero transform coefficient level associated with a first block of video data; determine a context for a second syntax element based on the value for the first syntax element, wherein the second syntax element indicates coding mode information for a second block of video data; and code the second syntax element based on the determined context.

This application claims the benefit of U.S. Provisional PatentApplication 62/503,218, filed 8 May 2017, the entire content of which ishereby incorporated by reference.

TECHNICAL FIELD

This disclosure relates to video encoding and video decoding.

BACKGROUND

Digital video capabilities can be incorporated into a wide range ofdevices, including digital televisions, digital direct broadcastsystems, wireless broadcast systems, personal digital assistants (PDAs),laptop or desktop computers, tablet computers, e-book readers, digitalcameras, digital recording devices, digital media players, video gamingdevices, video game consoles, cellular or satellite radio telephones,so-called “smart phones,” video teleconferencing devices, videostreaming devices, and the like. Digital video devices implement videocompression techniques, such as those described in the standards definedby MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Part 10, AdvancedVideo Coding (AVC), ITU-T H.265, High Efficiency Video Coding (HEVC),and extensions of such standards. The video devices may transmit,receive, encode, decode, and/or store digital video information moreefficiently by implementing such video compression techniques.

Video compression techniques perform spatial (intra picture) predictionand/or temporal (inter picture) prediction to reduce or removeredundancy inherent in video sequences. For block-based video coding, avideo slice (i.e., a video frame or a portion of a video frame) may bepartitioned into video blocks, which may also be referred to astreeblocks, coding units (CUs) and/or coding nodes. Video blocks in anintra coded (I) slice of a picture are encoded using spatial predictionwith respect to reference samples in neighboring blocks in the samepicture. Video blocks in an inter coded (P or B) slice of a picture mayuse spatial prediction with respect to reference samples in neighboringblocks in the same picture or temporal prediction with respect toreference samples in other reference pictures. Pictures may be referredto as frames, and reference pictures may be referred to as referenceframes.

Spatial or temporal prediction results in a predictive block for a blockto be coded. Residual data represents pixel differences between theoriginal block to be coded and the predictive block. An inter codedblock is encoded according to a motion vector that points to a block ofreference samples forming the predictive block, and the residual dataindicating the difference between the coded block and the predictiveblock. An intra coded block is encoded according to an intra coding modeand the residual data. For further compression, the residual data may betransformed from the pixel domain to a transform domain, resulting inresidual transform coefficients, which then may be quantized. Thequantized transform coefficients, initially arranged in atwo-dimensional array, may be scanned in order to produce aone-dimensional vector of transform coefficients, and entropy coding maybe applied to achieve even more compression.

SUMMARY

This disclosure describes techniques related to context modeling invideo codecs and, more specifically, describes techniques for selectingcontexts for syntax elements based on already coded information. Thetechniques of this disclosure may, for example, be used to performcontext modeling for Context-Adaptive Binary Arithmetic Coding (CABAC)or other context adaptive coding methods.

According to one example, a method of for coding video data includescoding a first syntax element, wherein a value for the first syntaxelement indicates whether there is at least one non-zero transformcoefficient level associated with a first block of video data;determining a context for a second syntax element based on the value forthe first syntax element, wherein the second syntax element indicatescoding mode information for a second block of video data; and coding thesecond syntax element based on the determined context.

According to another example, a device for coding video data includes amemory; and one or more processors configured to: code a first syntaxelement, wherein a value for the first syntax element indicates whetherthere is at least one non-zero transform coefficient level associatedwith a first block of video data; determine a context for a secondsyntax element based on the value for the first syntax element, whereinthe second syntax element indicates coding mode information for a secondblock of video data; and code the second syntax element based on thedetermined context.

According to another example, an apparatus for coding video dataincludes means for coding a first syntax element, wherein a value forthe first syntax element indicates whether there is at least onenon-zero transform coefficient level associated with a first block ofvideo data; means for determining a context for a second syntax elementbased on the value for the first syntax element, wherein the secondsyntax element indicates coding mode information for a second block ofvideo data; and means for coding the second syntax element based on thedetermined context.

According to another example, computer-readable storage medium storesinstructions that when executed cause one or more processors to code afirst syntax element, wherein a value for the first syntax elementindicates whether there is at least one non-zero transform coefficientlevel associated with a first block of video data; determine a contextfor a second syntax element based on the value for the first syntaxelement, wherein the second syntax element indicates coding modeinformation for a second block of video data; and code the second syntaxelement based on the determined context.

The details of one or more examples of the disclosure are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages will be apparent from the description, drawings,and claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating an example video encoding anddecoding system that may utilize the techniques described in thisdisclosure.

FIG. 2 shows an example of 8 partition modes for an inter-coded CU.

FIG. 3 shows an example of a transform tree structure within a CU.

FIG. 4A is a conceptual diagram illustrating an example of blockpartitioning using a quad-tree-binary-tree (QTBT) structure.

FIG. 4B is a conceptual diagram illustrating an example tree structurecorresponding to the block partitioning using the QTBT structure of FIG.4A.

FIG. 5 is a block diagram illustrating an example video encoder that mayimplement the techniques described in this disclosure.

FIG. 6 is a block diagram illustrating an example video decoder that mayimplement the techniques described in this disclosure.

FIGS. 7A and 7B are conceptual diagrams illustrating a range updateprocess in binary arithmetic coding.

FIG. 8 is a conceptual diagram illustrating an output process in binaryarithmetic coding.

FIG. 9 is a block diagram illustrating a context adaptive binaryarithmetic coding (CABAC) coder in a video encoder.

FIG. 10 is a block diagram illustrating a CABAC coder in a videodecoder.

FIG. 11 is a flowchart illustrating an example method of coding videodata in accordance with techniques described in this disclosure.

FIG. 12 is a flowchart illustrating an example method of coding videodata in accordance with techniques described in this disclosure.

DETAILED DESCRIPTION

This disclosure describes techniques related to context modeling invideo codecs and, more specifically, describes techniques for selectingcontexts for syntax elements based on already coded information. Thetechniques of this disclosure may, for example, be used to performcontext modeling for Context-Adaptive Binary Arithmetic Coding (CABAC)or other context adaptive coding methods. The techniques of thisdisclosure may be applied to any of the existing video codecs, such asHigh Efficiency Video Coding (HEVC), or may be an efficient coding toolfor a future video coding standard, such as a successor standard to HEVCor an extension to HEVC.

Various techniques in this disclosure may be described with reference tocoding, which is intended to be a generic term that can refer to eitherencoding or decoding. Likewise, the term coder may refer to either anencoder or a decoder. Unless explicitly stated otherwise, it should notbe assumed that techniques described with respect to a video encoder ora video decoder cannot be performed by the other of a video encoder or avideo decoder. For example, in many instances, a video decoder performsthe same, or sometimes a reciprocal, coding technique as a video encoderin order to decode encoded video data. In many instances, a videoencoder also includes a video decoding loop, and thus the video encoderperforms video decoding as part of encoding video data. Thus, unlessstated otherwise, the techniques described in this disclosure withrespect to a video decoder may also be performed by a video encoder, andvice versa.

This disclosure may also use terms such as current layer, current block,current picture, current slice, etc. In the context of this disclosure,the term current is intended to identify a layer, block, picture, slice,etc. that is currently being coded, as opposed to, for example,previously coded layers, blocks, pictures, and slices or yet to be codedblocks, pictures, and slices.

FIG. 1 is a block diagram illustrating an example video encoding anddecoding system 10 that may utilize the techniques described in thisdisclosure, including techniques for encoding and decoding blocks in anintra prediction mode. As shown in FIG. 1, system 10 includes a sourcedevice 12 that generates encoded video data to be decoded at a latertime by a destination device 14. Source device 12 and destination device14 may be any of a wide range of devices, including desktop computers,notebook (i.e., laptop) computers, tablet computers, set-top boxes,telephone handsets such as so-called “smart” phones, so-called “smart”pads, televisions, cameras, display devices, digital media players,video gaming consoles, video streaming device, or the like. In somecases, source device 12 and destination device 14 may be equipped forwireless communication.

Destination device 14 may receive the encoded video data to be decodedvia a link 16. Link 16 may be any type of medium or device capable ofmoving the encoded video data from source device 12 to destinationdevice 14. In one example, link 16 may be a communication medium toenable source device 12 to transmit encoded video data directly todestination device 14 in real-time. The encoded video data may bemodulated according to a communication standard, such as a wirelesscommunication protocol, and transmitted to destination device 14. Thecommunication medium may include any wireless or wired communicationmedium, such as a radio frequency (RF) spectrum or one or more physicaltransmission lines. The communication medium may form part of apacket-based network, such as a local area network, a wide-area network,or a global network such as the Internet. The communication medium mayinclude routers, switches, base stations, or any other equipment thatmay be useful to facilitate communication from source device 12 todestination device 14.

Alternatively, encoded data may be output from output interface 22 to astorage device 17. Similarly, encoded data may be accessed from storagedevice 17 by input interface. Storage device 17 may include any of avariety of distributed or locally accessed data storage media such as ahard drive, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile ornon-volatile memory, or any other suitable digital storage media forstoring encoded video data. In a further example, storage device 17 maycorrespond to a file server or another intermediate storage device thatmay hold the encoded video generated by source device 12. Destinationdevice 14 may access stored video data from storage device 17 viastreaming or download. The file server may be any type of server capableof storing encoded video data and transmitting that encoded video datato the destination device 14. Example file servers include a web server(e.g., for a website), an FTP server, network attached storage (NAS)devices, or a local disk drive. Destination device 14 may access theencoded video data through any standard data connection, including anInternet connection. This may include a wireless channel (e.g., a Wi-Ficonnection), a wired connection (e.g., DSL, cable modem, etc.), or acombination of both that is suitable for accessing encoded video datastored on a file server. The transmission of encoded video data fromstorage device 17 may be a streaming transmission, a downloadtransmission, or a combination of both.

The techniques of this disclosure are not necessarily limited towireless applications or settings. The techniques may be applied tovideo coding in support of any of a variety of multimedia applications,such as over-the-air television broadcasts, cable televisiontransmissions, satellite television transmissions, streaming videotransmissions, e.g., via the Internet, encoding of digital video forstorage on a data storage medium, decoding of digital video stored on adata storage medium, or other applications. In some examples, system 10may be configured to support one-way or two-way video transmission tosupport applications such as video streaming, video playback, videobroadcasting, and/or video telephony.

In the example of FIG. 1, source device 12 includes a video source 18,video encoder 20 and an output interface 22. In some cases, outputinterface 22 may include a modulator/demodulator (modem) and/or atransmitter. In source device 12, video source 18 may include a sourcesuch as a video capture device, e.g., a video camera, a video archivecontaining previously captured video, a video feed interface to receivevideo from a video content provider, and/or a computer graphics systemfor generating computer graphics data as the source video, or acombination of such sources. As one example, if video source 18 is avideo camera, source device 12 and destination device 14 may formso-called camera phones or video phones. However, the techniquesdescribed in this disclosure may be applicable to video coding ingeneral, and may be applied to wireless and/or wired applications.

The captured, pre-captured, or computer-generated video may be encodedby video encoder 20. The encoded video data may be transmitted directlyto destination device 14 via output interface 22 of source device 12.The encoded video data may also (or alternatively) be stored ontostorage device 17 for later access by destination device 14 or otherdevices, for decoding and/or playback.

Destination device 14 includes an input interface 28, a video decoder30, and a display device 34. In some cases, input interface 28 mayinclude a receiver and/or a modem. Input interface 28 of destinationdevice 14 receives the encoded video data over link 16. The encodedvideo data communicated over link 16, or provided on storage device 17,may include a variety of syntax elements generated by video encoder 20for use by a video decoder, such as video decoder 30, in decoding thevideo data. Such syntax elements may be included with the encoded videodata transmitted on a communication medium, stored on a storage medium,or stored a file server.

Display device 34 may be integrated with, or external to, destinationdevice 14. In some examples, destination device 14 may include anintegrated display device and also be configured to interface with anexternal display device. In other examples, destination device 14 may bea display device. In general, display device 34 displays the decodedvideo data to a user, and may be any of a variety of display devicessuch as a liquid crystal display (LCD), a plasma display, an organiclight emitting diode (OLED) display, or another type of display device.

Video encoder 20 and video decoder 30 may operate according to a videocompression standard, such as HEVC. HEVC, also referred to as ITU-TH.265, including its range extension, multiview extension (MV-HEVC) andscalable extension (SHVC), has recently been developed by the JointCollaboration Team on Video Coding (JCT-VC) as well as JointCollaboration Team on 3D Video Coding Extension Development (JCT-3V) ofITU-T Video Coding Experts Group (VCEG) and ISO/IEC Motion PictureExperts Group (MPEG). The HEVC standard, referred to as HEVChereinafter, is identified as Recommendation ITU-T H.265, Series H:Audiovisual and Multimedia Systems, Infrastructure of audiovisualservices—Coding of moving video, High efficiency video coding, December2016. The latest HEVC draft specification is available fromhttp://phenix.int-evey.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1.zip.The latest HEVC draft including several extensions is available from:http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=10481.

Alternatively or additionally, video encoder 20 and video decoder 30 mayoperate according to other future or existing proprietary or industrystandards, such as the ITU-T H.264 standard, also referred to as MPEG-4,Part 10, Advanced Video Coding (AVC), or extensions of such standards.The techniques of this disclosure, however, are not limited to anyparticular coding standard. Other examples of video compressionstandards include ITU-T H.261, ISO/IEC MPEG-1 Visual, ITU-T H.262 orISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual and ITU-TH.264 (also known as ISO/IEC MPEG-4 AVC), including its Scalable VideoCoding (SVC) and Multiview Video Coding (MVC) extensions. Video codingstandards also include proprietary video codecs, such as VP8, VP9, VP10,and video codecs developed by other organizations such as, for example,the Alliance for Open Media.

ITU-T VCEG (Q6/16) and ISO/IEC MPEG (JTC 1/SC 29/WG 11) are now studyingthe potential for standardization of future video coding technology witha compression capability that potentially exceeds that of the currentHEVC standard (including its current extensions and near-term extensionsfor screen content coding and high-dynamic-range coding). The groups areworking together on this exploration activity in joint collaborationefforts known as the Joint Video Exploration Team (JVET) to evaluatecompression technology designs proposed by their experts in this area.The JVET first meeting was held during 19-21 Oct. 2015. The latestversion of JVET reference software, i.e., Joint Exploration Model 5 (JEM5) can be downloaded from:https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16.6-JEM-5.0/.An algorithm description of JEM5 may be referred to as JVET-E1001.

It is generally contemplated that video encoder 20 of source device 12may be configured to encode video data according to any of these currentor future standards. Similarly, it is also generally contemplated thatvideo decoder 30 of destination device 14 may be configured to decodevideo data according to any of these current or future standards. Someof the techniques of this disclosure may be described utilizing HEVCterminology for ease of explanation. Such techniques, however, are notnecessarily limited to HEVC, and in fact, it is explicitly contemplatedthat such techniques may be applicable to future standards such assuccessor standards to HEVC.

Although not shown in FIG. 1, in some aspects, video encoder 20 andvideo decoder 30 may each be integrated with an audio encoder anddecoder, and may include appropriate MUX-DEMUX units, or other hardwareand software, to handle encoding of both audio and video in a commondata stream or separate data streams. If applicable, in some examples,MUX-DEMUX units may conform to the ITU H.223 multiplexer protocol, orother protocols such as the user datagram protocol (UDP).

Video encoder 20 and video decoder 30 each may be implemented as any ofa variety of suitable encoder circuitry, such as one or moremicroprocessors, digital signal processors (DSPs), application specificintegrated circuits (ASICs), field programmable gate arrays (FPGAs),discrete logic, software, hardware, firmware or any combinationsthereof. When the techniques are implemented partially in software, adevice may store instructions for the software in a suitable,non-transitory computer-readable medium and execute the instructions inhardware using one or more processors to perform the techniques of thisdisclosure. Each of video encoder 20 and video decoder 30 may beincluded in one or more encoders or decoders, either of which may beintegrated as part of a combined encoder/decoder (CODEC) in a respectivedevice.

As introduced above, the JCT-VC has recently finalized development ofthe HEVC standard. In HEVC and other video coding specifications, avideo sequence typically includes a series of pictures. Pictures mayalso be referred to as “frames.” A picture may include three samplearrays, denoted S_(L), S_(Cb), and S_(Cr). S_(L) is a two-dimensionalarray (i.e., a block) of luma samples. S_(Cb) is a two-dimensional arrayof Cb chrominance samples. S_(Cr) is a two-dimensional array of Crchrominance samples. Chrominance samples may also be referred to hereinas “chroma” samples. In other instances, a picture may be monochrome andmay only include an array of luma samples.

To generate an encoded representation of a picture, video encoder 20 maygenerate a set of coding tree units (CTUs). Each of the CTUs may includea coding tree block (CTB) of luma samples, two corresponding coding treeblocks of chroma samples, and syntax structures used to code the samplesof the coding tree blocks. In monochrome pictures or pictures havingthree separate color planes, a CTU may include a single coding treeblock and syntax structures used to code the samples of the coding treeblock. A coding tree block may be an N×N block of samples. A CTU mayalso be referred to as a “tree block” or a “largest coding unit” (LCU).The CTUs of HEVC may be broadly analogous to the macroblocks of otherstandards, such as H.264/AVC. However, a CTU is not necessarily limitedto a particular size and may include one or more coding units (CUs). Aslice may include an integer number of CTUs ordered consecutively in araster scan order.

To generate a coded CTU, video encoder 20 may recursively performquad-tree partitioning on the coding tree blocks of a CTU to divide thecoding tree blocks into coding blocks, hence the name “coding treeunits.” A coding block may be an N×N block of samples. A CU may includea coding block of luma samples and two corresponding coding blocks ofchroma samples of a picture that has a luma sample array, a Cb samplearray, and a Cr sample array, and syntax structures used to code thesamples of the coding blocks. In monochrome pictures or pictures havingthree separate color planes, a CU may include a single coding block andsyntax structures used to code the samples of the coding block.

Video encoder 20 may partition a coding block of a CU into one or moreprediction blocks. A prediction block is a rectangular (i.e., square ornon-square) block of samples on which the same prediction is applied. Aprediction unit (PU) of a CU may include a prediction block of lumasamples, two corresponding prediction blocks of chroma samples, andsyntax structures used to predict the prediction blocks. In monochromepictures or pictures having three separate color planes, a PU mayinclude a single prediction block and syntax structures used to predictthe prediction block. Video encoder 20 may generate predictive luma, Cb,and Cr blocks for luma, Cb, and Cr prediction blocks of each PU of theCU.

Video encoder 20 may use intra prediction or inter prediction togenerate the predictive blocks for a PU. If video encoder 20 uses intraprediction to generate the predictive blocks of a PU, video encoder 20may generate the predictive blocks of the PU based on decoded samples ofthe picture associated with the PU. If video encoder 20 uses interprediction to generate the predictive blocks of a PU, video encoder 20may generate the predictive blocks of the PU based on decoded samples ofone or more pictures other than the picture associated with the PU.

After video encoder 20 generates predictive luma, Cb, and Cr blocks forone or more PUs of a CU, video encoder 20 may generate a luma residualblock for the CU. Each sample in the CU's luma residual block indicatesa difference between a luma sample in one of the CU's predictive lumablocks and a corresponding sample in the CU's original luma codingblock. In addition, video encoder 20 may generate a Cb residual blockfor the CU. Each sample in the CU's Cb residual block may indicate adifference between a Cb sample in one of the CU's predictive Cb blocksand a corresponding sample in the CU's original Cb coding block. Videoencoder 20 may also generate a Cr residual block for the CU. Each samplein the CU's Cr residual block may indicate a difference between a Crsample in one of the CU's predictive Cr blocks and a correspondingsample in the CU's original Cr coding block.

Furthermore, video encoder 20 may use quad-tree partitioning todecompose the luma, Cb, and Cr residual blocks of a CU into one or moreluma, Cb, and Cr transform blocks. A transform block is a rectangular(e.g., square or non-square) block of samples on which the sametransform is applied. A transform unit (TU) of a CU may include atransform block of luma samples, two corresponding transform blocks ofchroma samples, and syntax structures used to transform the transformblock samples. Thus, each TU of a CU may be associated with a lumatransform block, a Cb transform block, and a Cr transform block. Theluma transform block associated with the TU may be a sub-block of theCU's luma residual block. The Cb transform block may be a sub-block ofthe CU's Cb residual block. The Cr transform block may be a sub-block ofthe CU's Cr residual block. In monochrome pictures or pictures havingthree separate color planes, a TU may include a single transform blockand syntax structures used to transform the samples of the transformblock.

Video encoder 20 may apply one or more transforms to a luma transformblock of a TU to generate a luma coefficient block for the TU. Acoefficient block may be a two-dimensional array of transformcoefficients. A transform coefficient may be a scalar quantity. Videoencoder 20 may apply one or more transforms to a Cb transform block of aTU to generate a Cb coefficient block for the TU. Video encoder 20 mayapply one or more transforms to a Cr transform block of a TU to generatea Cr coefficient block for the TU.

After generating a coefficient block (e.g., a luma coefficient block, aCb coefficient block or a Cr coefficient block), video encoder 20 mayquantize the coefficient block. Quantization generally refers to aprocess in which transform coefficients are quantized to possibly reducethe amount of data used to represent the transform coefficients,providing further compression. After video encoder 20 quantizes acoefficient block, video encoder 20 may entropy encode syntax elementsindicating the quantized transform coefficients. For example, videoencoder 20 may perform CABAC on the syntax elements indicating thequantized transform coefficients.

Video encoder 20 may output a bitstream that includes a sequence of bitsthat forms a representation of coded pictures and associated data. Thebitstream may include a sequence of network abstraction layer (NAL)units. A NAL unit is a syntax structure containing an indication of thetype of data in the NAL unit and bytes containing that data in the formof a raw byte sequence payload (RBSP) interspersed as necessary withemulation prevention bits. Each of the NAL units includes a NAL unitheader and encapsulates a RBSP. The NAL unit header may include a syntaxelement that indicates a NAL unit type code. The NAL unit type codespecified by the NAL unit header of a NAL unit indicates the type of theNAL unit. A RBSP may be a syntax structure containing an integer numberof bytes that is encapsulated within a NAL unit. In some instances, anRBSP includes zero bits.

Different types of NAL units may encapsulate different types of RBSPs.For example, a first type of NAL unit may encapsulate an RBSP for apicture parameter set (PPS), a second type of NAL unit may encapsulatean RBSP for a coded slice, a third type of NAL unit may encapsulate anRBSP for SEI messages, and so on. NAL units that encapsulate RBSPs forvideo coding data (as opposed to RBSPs for parameter sets and SEImessages) may be referred to as video coding layer (VCL) NAL units.

Video decoder 30 may receive a bitstream generated by video encoder 20.In addition, video decoder 30 may parse the bitstream to obtain syntaxelements from the bitstream. Video decoder 30 may reconstruct thepictures of the video data based at least in part on the syntax elementsobtained from the bitstream. The process to reconstruct the video datamay be generally reciprocal to the process performed by video encoder20. In addition, video decoder 30 may inverse quantize coefficientblocks associated with TUs of a current CU. Video decoder 30 may performinverse transforms on the coefficient blocks to reconstruct transformblocks associated with the TUs of the current CU. Video decoder 30 mayreconstruct the coding blocks of the current CU by adding the samples ofthe predictive blocks for PUs of the current CU to corresponding samplesof the transform blocks of the TUs of the current CU. By reconstructingthe coding blocks for each CU of a picture, video decoder 30 mayreconstruct the picture.

As introduced above, in HEVC, the largest coding unit in a slice may becalled a CTB. A CTB contains a quad-tree of the nodes of which arecoding units. The size of a CTB can be in ranges from 16×16 to 64×64 inthe HEVC main profile (although technically 8×8 CTB sizes can besupported). A CU can be the same size of a CTB though and as small as8×8. Each coding unit is coded with one mode. When a CU is inter coded,the CU may be further partitioned into 2 or 4 PUs or become just one PUwithout further partitioning. When two PUs are present in one CU, thetwo PUs can be half size rectangles or two rectangles with ¼ and ¾ thesize of the CU, respectively.

When the CU is inter coded, one set of motion information is present foreach PU. In addition, each PU is coded with a unique inter-predictionmode to derive the set of motion information.

A PU is a region, defined by partitioning the CU, on which the sameprediction is applied. In general, the PU is not restricted to beingsquare in shape, in order to facilitate partitioning which matches theboundaries of real objects in the picture.

FIG. 2 shows an example of 8 partition modes for an inter-coded CU. EachCU contains one, two or four PUs depending on the partition mode. FIG. 2illustrates the eight partition modes that may be used to define the PUsfor an inter-coded CU. The PART_2N×2N and PART_N×N partition modes areused for an intra-coded CU. The partition mode PART_N×N is allowed onlywhen the corresponding CU size is equal to the minimum CU size.

Merge flags for an inter predicted prediction unit will now bedescribed. A merge flag of an inter predicted prediction unit equal to 1specifies that the motion information (motion vector and referenceindex) is the same as one candidate. In this case, only the candidateindex is signaled in the bitstream rather than the actual motioninformation.

Table 7.3.8.6 of the HEVC standard, shown below, shows an example ofprediction unit syntax.

7.3.8.6 Prediction unit syntax prediction_unit( x0, y0, nPbW, nPbH ) {Descriptor  if( cu_skip_flag[ x0 ][ y0 ] ) {   if( MaxNumMergeCand > 1 )   merge_idx[ x0 ][ y0 ] ae(v)  } else { /* MODE_INTER */   merge_flag[x0 ][ y0 ] ae(v)   if( merge_flag[ x0 ][ y0 ] ) {    if(MaxNumMergeCand > 1 )     merge_idx[ x0 ][ y0 ] ae(v)   } else {    if(slice_type = = B )     inter_pred_idc[ x0 ][ y0 ] ae(v)    if(inter_pred_idc[ x0 ][ y0 ] != PRED_L1 ) {     if(num_ref_idx_l0_active_minus1 > 0 )      ref_idx_l0[ x0 ][ y0 ] ae(v)    mvd_coding( x0, y0, 0 )     mvp_l0_flag[ x0 ][ y0 ] ae(v)    }   if( inter_pred_idc[ x0 ][ y0 ] != PRED_L0 ) {     if(num_ref_idx_l1_active_minus1 > 0 )      ref_idx_l1[ x0 ][ y0 ] ae(v)    if( mvd_l1_zero_flag &&       inter_pred_idc[ x0 ][ y0 ] = = PRED_BI) {      MvdL1[ x0 ][ y0 ][ 0 ] = 0      MvdL1[ x0 ][ y0 ][ 1 ] = 0    } else      mvd_coding( x0, y0, 1 )     mvp_l1_flag[ x0 ][ y0 ]ae(v)    }   }  } }

Aspects of a TU and transform tree structure will now be described. EachCU corresponds to one transform tree, which is a quad-tree, the leaf ofwhich is a transform unit.

The transform unit (TU) is a square region, defined by quadtreepartitioning of the CU, which shares the same transform and quantizationprocesses. The quadtree structure of multiple TUs within a CU isillustrated in FIG. 3.

FIG. 3 shows an example of a transform tree structure within a CU. Inthe example of FIG. 3, the TU shape is always square and may take a sizefrom 32×32 down to 4×4 samples. The maximum quadtree depth is adjustableand is specified in the slice header syntax. For an inter CU, the TU canbe larger than the PU, i.e., the TU may contain PU boundaries. However,the TU cannot cross PU boundaries for an intra-coded CU.

Rqt_root_cbf equal to 1 specifies that the transform_tree syntaxstructure is present for the current coding unit. rqt_root_cbf equal to0 specifies that the transform_tree syntax structure is not present forthe current coding unit. When rqt_root_cbf is not present, its value isinferred to be equal to 1.

When rqt_root_cbf is equal to 0, the transform tree only contains onenode, meaning the node is not further split and the split_transform_flagis equal to 0. In addition, when rqt_root_cbf is equal to 0, there is noneed to perform a transform for the CU. A node inside a transform treethat has split_transform_flag equal to 1 is further split into fournodes. A leaf of the transform tree has a split_transform_flag equal to0.

For simplicity, if a transform unit or transform tree corresponds to ablock which does not have a transform, a transform tree or transformunit is still treated as a transform tree or transform unit because thehierarchy of the transform itself still exists. Typically, a transformskipped block is within a transform unit.

Aspect of coded block flag (cbf) of a TU will now be described. A cbf ofa transform unit equal to 1 specifies that the transform unit containsone or more transform coefficient levels not equal to 0. The value ofcbf of a transform unit equal to 0 specifies that all transformcoefficient levels of the transform unit are 0. The value of cbf is setfor each component of the transform unit, i.e., the value of cbf is setfor luma, cb and cr component respectively.

Table 7.3.8.5 of the HEVC standard below shows an example of CU syntax.

7.3.8.5 Coding unit syntax coding_unit( x0, y0, log2CbSize ) {Descriptor ...    if( !pcm_flag[ x0 ][ y0 ] ) {     if( CuPredMode[ x0][ y0 ] != MODE_INTRA &&      !( PartMode = = PART_2N×2N && merge_flag[x0 ][ y0 ] ) )      rqt_root_cbf ae(v)     if( rqt_root_cbf ) {     MaxTrafoDepth = ( CuPredMode[ x0 ][ y0 ] = = MODE_INTRA ?               ( max_transform_hierarchy_depth_intra + IntraSplitFlag ):                max_transform_hierarchy_depth_inter )     transform_tree( x0, y0, x0, y0, log2CbSize, 0, 0 )     }    }   } } }

Table 7.3.8.8 of the HEVC standard below shows an example of transformtree syntax.

7.3.8.8 Transform tree syntax transform_tree( x0, y0, xBase, yBase,log2TrafoSize, trafoDepth, blkIdx ) { Descriptor  if( log2TrafoSize <=MaxTbLog2SizeY &&   log2TrafoSize > MinTbLog2SizeY &&   trafoDepth <MaxTrafoDepth && !( IntraSplitFlag && ( trafoDepth = = 0 ) ) )  split_transform_flag[ x0 ][ y0 ][ trafoDepth ] ae(v)  if( (log2TrafoSize > 2 && ChromaArrayType != 0 ) || ChromaArrayType = = 3 ) {  if( trafoDepth = = 0 || cbf_cb[ xBase ][ yBase ][ trafoDepth − 1 ] ) {   cbf_cb[ x0 ][ y0 ][ trafoDepth ] ae(v)    if( ChromaArrayType = = 2&&     ( !split_transform_flag[ x0 ][ y0 ][ trafoDepth ] ||log2TrafoSize = = 3 ) )     cbf_cb[ x0 ][ y0 + ( 1 << ( log2TrafoSize −1 ) ) ][ trafoDepth ] ae(v)   }   if( trafoDepth = = 0 || cbf_cr[ xBase][ yBase ][ trafoDepth − 1 ] ) {    cbf_cr[ x0 ][ y0 ][ trafoDepth ]ae(v)    if( ChromaArrayType = = 2 &&     ( !split_transform_flag[ x0 ][y0 ][ trafoDepth ] || log2TrafoSize = = 3 ) )     cbf_cr[ x0 ][ y0 + ( 1<< ( log2TrafoSize − 1 ) ) ][ trafoDepth ] ae(v)  }  }  if(split_transform_flag[ x0 ][ y0 ][ trafoDepth ] ) {   x1 = x0 + ( 1 << (log2TrafoSize − 1 ) )   y1 = y0 + ( 1 << ( log2TrafoSize − 1 ) )  transform_tree( x0, y0, x0, y0, log2TrafoSize − 1, trafoDepth + 1, 0 )  transform_tree( x1, y0, x0, y0, log2TrafoSize − 1, trafoDepth + 1, 1 )  transform_tree( x0, y1, x0, y0, log2TrafoSize − 1, trafoDepth + 1, 2 )  transform_tree( x1, y1, x0, y0, log2TrafoSize − 1, trafoDepth + 1, 3 ) } else {   if( CuPredMode[ x0 ][ y0 ] = = MODE_INTRA || trafoDepth != 0||    cbf_cb[ x0 ][ y0 ][ trafoDepth ] || cbf_cr[ x0 ][ y0 ][ trafoDepth] ||    ( ChromaArrayType = = 2 &&     ( cbf_cb[ x0 ][ y0 + ( 1 << (log2TrafoSize − 1 ) ) ][ trafoDepth ] ||      cbf_cr[ x0 ][ y0 + ( 1 <<( log2TrafoSize − 1 ) ) ][ trafoDepth ] ) ) )    cbf_luma[ x0 ][ y0 ][trafoDepth ] ae(v)   transform_unit( x0, y0, xBase, yBase,log2TrafoSize, trafoDepth, blkIdx )  } }

Section 7.4.9.8 of the HEVC standard describes the transform treesemantics as follows:

split_transform_flag[x0][y0][trafoDepth] specifies whether a block issplit into four blocks with half horizontal and half vertical size forthe purpose of transform coding. The array indices x0, y0 specify thelocation (x0, y0) of the top-left luma sample of the considered blockrelative to the top-left luma sample of the picture. The array indextrafoDepth specifies the current subdivision level of a coding blockinto blocks for the purpose of transform coding. trafoDepth is equal to0 for blocks that correspond to coding blocks.The Variable InterSplitFlag is Derived as Follows:

-   -   If max_transform_hierarchy_depth_inter is equal to 0 and        CuPredMode[x0][y0] is equal to MODE_INTER and PartMode is not        equal to PART_2N×2N and trafoDepth is equal to 0, interSplitFlag        is set equal to 1.    -   Otherwise, interSplitFlag is set equal to 0.        When split_transform_flag[x0][y0][trafoDepth] is not present, it        is inferred as follows:    -   If one or more of the following conditions are true, the value        of split_transform_flag[x0][y0][trafoDepth] is inferred to be        equal to 1:        -   log 2TrafoSize is greater than Max Tb Log 2SizeY.        -   IntraSplitFlag is equal to 1 and trafoDepth is equal to 0.        -   interSplitFlag is equal to 1.    -   Otherwise, the value of split_transform_flag[x0][y0][trafoDepth]        is inferred to be equal to 0.        cbf_luma[x0][y0][trafoDepth] equal to 1 specifies that the luma        transform block contains one or more transform coefficient        levels not equal to 0. The array indices x0, y0 specify the        location (x0, y0) of the top-left luma sample of the considered        transform block relative to the top-left luma sample of the        picture. The array index trafoDepth specifies the current        subdivision level of a coding block into blocks for the purpose        of transform coding. trafoDepth is equal to 0 for blocks that        correspond to coding blocks. When cbf_luma[x0][y0][trafoDepth]        is not present, it is inferred to be equal to 1.

cbf_cb[x0][y0][trafoDepth] equal to 1 specifies that the Cb transformblock contains one or more transform coefficient levels not equal to 0.The array indices x0, y0 specify the top-left location (x0, y0) of theconsidered transform block. The array index trafoDepth specifies thecurrent subdivision level of a coding block into blocks for the purposeof transform coding. trafoDepth is equal to 0 for blocks that correspondto coding blocks. When cbf_cb[x0][y0][trafoDepth] is not present, it isinferred to be equal to 0.

cbf_cr[x0][y0][trafoDepth] equal to 1 specifies that the Cr transformblock contains one or more transform coefficient levels not equal to 0.The array indices x0, y0 specify the top-left location (x0, y0) of theconsidered transform block. The array index trafoDepth specifies thecurrent subdivision level of a coding block into blocks for the purposeof transform coding. trafoDepth is equal to 0 for blocks that correspondto coding blocks. When cbf_cr[x0][y0][trafoDepth] is not present, it isinferred to be equal to 0.

Table 9-4 below shows an association of context index (ctxIdx) andsyntax elements for each initializationType in the initializationprocess.

TABLE 9-4 Syntax initType structure Syntax element ctxTable 0 1 2transform_tree( ) split_transform_flag[ ][ ][ ] Table 9-20 0 . . . 2 3 .. . 5 6 . . . 8 cbf_luma[ ][ ][ ] Table 9-21 0 . . . 1 2 . . . 3 4 . . .5 cbf_cb[ ][ ][ ], Table 9-22 0 . . . 3 4 . . . 7  8 . . . 11 cbf_cr[ ][][ ]

Table 9-21 below shows an example of values of initValue for ctxIdx ofcbf_luma.

TABLE 9-21 Initialization ctxIdx of cbf_luma variable 0 1 2 3 4 5initValue 111 141 153 111 153 111

Table 9-22 below shows an example of values of initValue for ctxIdx ofcbf_cb and cbf_cr.

TABLE 9-22 Initialization ctxIdx of cbf_cb and cbf_cr variable 0 1 2 3 45 6 7 8 9 10 11 initValue 94 138 182 154 149 107 167 154 149 92 167 154

Aspects of context modeling will now be described. More than 1 contextmay be used to code cbf. More specifically, the transform depth may beutilized to select the context index. Detailed information can be foundin the table below. More specifically, the selection of cbf_luma isdepending on whether the transform depth (i.e., trafoDepth) is equal to0 or not, while the selection of cbf_cb and cbf_cr is depending on thetransform depth. In HEVC, the transform depth could be from 0 to 3;therefore, 4 contexts may be used to code cbf_cb and cbf_cr.

Table 9-48 below shows an assignment of context index increment (ctxInc)to syntax elements with context coded bins.

TABLE 9-48 cbf_cb[ ][ ][ ] trafoDepth na na na na na cbf_cr[ ][ ][ ]trafoDepth na na na na na cbf_luma[ ][ ][ ] trafoDepth = = 0 ? 1 : 0 nana na na na

QTBT structure, as described in H. Huang, K. Zhang, Y.-W. Huang, S. Lei,“EE2.1: Quadtree plus binary tree structure integration with JEM tools”,JVET-C0024, June, 2016, which is incorporated herein in its entirety, isadopted in the JEM software. In the QTBT structure, a coding tree block(CTB) is firstly partitioned by a quadtree structure. The quadtree leafnodes are further partitioned by a binary tree structure. The binarytree leaf nodes, namely coding blocks (CBs), are used for prediction andtransform without any further partitioning. For P and B slices, the lumaand chroma CTBs in one coding tree unit (CTU) share the same QTBTstructure. For an I slice, the luma CTB is partitioned into CBs by aQTBT structure, and two chroma CTBs are partitioned into chroma CBs byanother QTBT structure.

A CTU (or CTB for I slice), which is the root node of a quadtree, isfirstly partitioned by a quadtree, where the quadtree splitting of onenode can be iterated until the node reaches the minimum allowed quadtreeleaf node size (Min QTSize). If the quadtree leaf node size is notlarger than the maximum allowed binary tree root node size (Max BTSize),then the quadtree leaf node can be further partitioned by a binary tree.The binary tree splitting of one node can be iterated until the nodereaches the minimum allowed binary tree leaf node size (Min BTSize) orthe maximum allowed binary tree depth (Max BTDepth). The binary treeleaf node, namely CU (or CB for I slice), will be used for prediction(e.g. intra-picture or inter-picture prediction) and transform withoutany further partitioning. That is, in the QTBT structure, the conceptsof CU/PU/TU is aligned and the three are always the same.

There are two splitting types in the binary tree splitting: symmetrichorizontal splitting and symmetric vertical splitting.

In one example of the QTBT partitioning structure, the CTU size is setto 128×128 (luma samples and corresponding 64×64 Cb/Cr samples), the MinQTSize is set to 16×16, the Max BTSize is set to 64×64, the Min BTSize(for both width and height) is set to 4, and the Max BTDepth is set to4. The quadtree partitioning is applied to the CTU first to generatequadtree leaf nodes. The quadtree leaf nodes may have a size from 16×16(i.e., the Min QTSize) to 128×128 (i.e., the CTU size). If the leafquadtree node is 128×128, then the leaf quadtree now is not furthersplit by the binary tree because the size exceeds the Max BTSize (i.e.,64×64). Otherwise, the leaf quadtree node will be further partitioned bythe binary tree. Therefore, the quadtree leaf node is also the root nodefor the binary tree and its binary tree depth is defined as 0. Thebinary tree depth reaching Max BTDepth (i.e., 4) implies no furthersplitting. The binary tree node having a width equal to Min BTSize(i.e., 4) implies no further horizontal splitting. Similarly, the binarytree node having a height equal to Min BTSize implies no furthervertical splitting. The leaf nodes of the binary tree, namely CUs, arefurther processed by prediction and transform without any furtherpartitioning.

FIG. 4A illustrates an example of block partitioning by using QTBT, andFIG. 4B illustrates the corresponding tree structure. The solid linesindicate quadtree splitting and dotted lines indicate binary treesplitting. In each splitting (i.e., non-leaf) node of the binary tree,one flag is signaled to indicate which splitting type (i.e., horizontalor vertical) is used, where 0 indicates horizontal splitting and 1indicates vertical splitting. For the quadtree splitting, there is noneed to indicate the splitting type because blocks always splithorizontally and vertically into 4 sub-blocks of equal size.

FIG. 4A illustrates an example of a block 150 (e.g., a CTB) partitionedusing QTBT partitioning techniques. As shown in FIG. 4A, using QTBTpartition techniques, each of the resultant blocks is splitsymmetrically through the center of each block. FIG. 4B illustrates thetree structure corresponding to the block partitioning of FIG. 4A. Thesolid lines in FIG. 4B indicate quad-tree splitting and dotted linesindicate binary-tree splitting. In one example, in each splitting (i.e.,non-leaf) node of the binary-tree, a syntax element (e.g., a flag) issignaled to indicate the type of splitting performed (e.g., horizontalor vertical), where 0 indicates horizontal splitting and 1 indicatesvertical splitting. For the quad-tree splitting, there is no need toindicate the splitting type, as quad-tree splitting always splits ablock horizontally and vertically into 4 sub-blocks with an equal size.

As shown in FIG. 4B, at node 170, block 150 is split into the fourblocks 151, 152, 153, and 154, shown in FIG. 4A, using QT partitioning.Block 154 is not further split, and is therefore a leaf node. At node172, block 151 is further split into two blocks using BT partitioning.As shown in FIG. 4B, node 172 is marked with a 1, indicating verticalsplitting. As such, the splitting at node 172 results in block 157 andthe block including both blocks 155 and 156. Blocks 155 and 156 arecreated by a further vertical splitting at node 174. At node 176, block152 is further split into two blocks 158 and 159 using BT partitioning.

At node 178, block 153 is split into 4 equal size blocks using QTpartitioning. Blocks 163 and 166 are created from this QT partitioningand are not further split. At node 180, the upper left block is firstsplit using vertical binary-tree splitting resulting in block 160 and aright vertical block. The right vertical block is then split usinghorizontal binary-tree splitting into blocks 161 and 162. The lowerright block created from the quad-tree splitting at node 178 is split atnode 184 using horizontal binary-tree splitting into blocks 164 and 165.

For an I slice, a luma-chroma-separated block partitioning structure isproposed. The luma component of one CTU (i.e., the luma CTB) ispartitioned by a QTBT structure into luma CBs, and the two chromacomponents of that CTU (i.e., the two chroma CTBs) are partitioned byanother QTBT structure into chroma CBs.

For P and B slice, the block partitioning structure for luma and chromais shared. That is, one CTU (including both luma and chroma) ispartitioned by one QTBT structure into CUs.

Context modeling for cbf in QTBT will now be described. In QTBT, thecontext modeling of cbf is still dependent on the transform depth.However, the transform size is always equal to the CU/PU size in QTBT,that is, the transform depth is always set to 0. Therefore, only onecontext is used for one slice type for coding cbf_luma; and anothercontext is used to code cbf_cb and cbf_cr together. In JEM, only onecontext is used for coding a merge flag.

The design of context modeling in JEM may have some potential problems.As one example, one context may not be able to capture the differentcharacteristics of cbf distributions under different modes. According tooffline statistics, the chance of cbf being equal to 1 for intra codedluma blocks is typically higher than that for inter coded luma blocksfor video blocks coded with the same quantization parameter. As anotherexample of a potential problem, the relationship between cbf and othersyntax elements is not currently utilized.

This disclosure described techniques that may address the aboveproblems. Some of the techniques of this disclosure may be combined.Additionally, the proposed techniques may not be restricted to codingstructures where a TU is always equal (e.g., in size and shape) to acorresponding CU/PU.

According to techniques of this disclosure, video encoder 20 and videodecoder 30 may perform context modeling of the syntax element thatindicates whether there is at least one non-zero transform coefficientlevel in a block (e.g., cbf_luma/cbf_cb/cbf_cr in HEVC specification)that is dependent on coded information. The coded information may, forexample, be defined as the coding mode, for example, intra or intercoded modes. Therefore, blocks within a slice/picture coded with intraor inter modes may utilize different contexts to code the syntaxelement. Additionally or alternatively, the coded information may bedefined as block sizes. For purposes of example, it can be assumed thatthe transform block size is denoted by W*H, with W indicating the widthof the transform block and H indicating the height of the transformblock. In one example, the coded information may be defined as log2(W)+log 2(H) or W*H or min(W, H) or max(W, H). Additionally oralternatively, the coded information may be defined as the shape oftransform blocks, e.g., square or non-square; or defined as thetransform types. The same context modeling method may be applied toselect contexts for different color components although the contexts maybe separated for different color components.

According to other techniques of this disclosure, video encoder 20 andvideo decoder 30 may use transform coefficient level information ofneighboring blocks to code some syntax elements of current blocks. Ifneighboring blocks have few non-zero quantized coefficients, a currentblock is probable to be a stable area, i.e., an area which is easy topredict due to low low residual energy, which may be indicative of lowspatial variance or low temporal variance. In one example, video encoder20 and video decoder 30 may use cbf values of neighboring blocks toselect contexts for coding the merge flag. In another example, videoencoder 20 and video decoder 30 may use cbf values of neighboring blocksto select contexts for prediction mode. In one example, the neighboringblocks are those blocks which are adjacent to current block withincurrent slice/tile/picture. In one example, the neighboring block may bethe co-located block in a reference picture or adjacent neighboringblocks of the co-located block.

Examples of context modeling of cbf depending on coded modes will now bedescribed. The tables below have been modified, compared to thelike-numbered tables above, in accordance with techniques of thisdisclosure.

TABLE 9-4 Association of ctxIdx and syntax elements for eachinitializationType in the initialization process Syntax initTypestructure Syntax element ctxTable 0 1 2 transform_tree( )split_transform_flag[ ][ ][ ] Table 9-20 0 . . . 2 3 . . . 5 6 . . . 8cbf_luma[ ][ ][ ] Table 9-21 0 . . . 1 2 . . . 3 4 . . . 5 cbf_cb[ ][ ][], Table 9-22 0 . . . 1 2 . . . 3 4 . . . 5 cbf_cr[ ][ ][ ]

TABLE 9-21 Values of initValue for ctxIdx of cbf_luma InitializationctxIdx of cbf_luma variable 0 1 2 3 4 5 initValue 141 141 111 111 111111

TABLE 9-22 Values of initValue for ctxIdx of cbf_cb and cbf_crInitialization ctxIdx of cbf_cb and cbf_cr variable 0 1 2 3 4 5initValue 94 94 149 149 149 149

Video encoder 20 and video decoder 30 may perform context modeling asdescribed in more detail below. More than 1 context may be used to codecbf. More specifically, the transform depth may be utilized to selectthe context index. Detailed example information is shown in the tablebelow.

The selection of cbf_luma is depending on whether the transform depth(i.e., trafoDepth) is equal to 0 or not, while the selection of cbf_cband cbf_cr is depending on the transform depth. In HEVC, the transformdepth could be from 0 to 3; therefore, 4 contexts may be used to codecbf_cb and cbf_cr.

Table 9-48 below shows an example of assignment of ctxInc to syntaxelements with context coded bins, as updated based on the techniques ofthis disclosure.

TABLE 9-48 cbf_cb[ ][ ][ ] codedMode na na Na na na cbf_cr[ ][ ][ ]codedMode na na Na na na = = Intra ? 0 : 1 cbf_luma[ ][ ][ ] codedModeNa na Na na na = = Intra ? 0 : 1

Video encoder 20 and video decoder 30 may perform context modeling for amerge flag. More than one context may be used to code a merge flag.According to one example, the cbfs from two neighbour (left and top)luma blocks may be utilized, ctxInc=cbf_top+cbf_left

Video encoder 20 and video decoder 30 may perform context modeling for acbf depending on TU sizes. Compared to large blocks, small blocks areeasier to predict. As such, small blocks are more probable to have fewernon-zero quantized coefficients. The context modeling of cbf can dependon TU sizes.

Denote the width and height of a TU by W and H, respectively. In oneexample, Table 9-48 can be refined as:

TABLE 9-48 Assignment of ctxInc to syntax elements with context codedbins cbf_cb[ ][ ][ ] (codedMode == inter || na na na na nalog2(W)+log2(H) <= 6) ? 0 : 1 cbf_cr[ ][ ][ ] (codedMode == inter || nana na na na log2(W)+log2(H) <= 6) ? 0 : 1 cbf_luma[ ][ ][ ] (codedMode== inter || na na na na na log2(W)+log2(H) <= 6) ? 0 : 1

FIG. 5 is a block diagram illustrating an example video encoder 20 thatmay implement the techniques described in this disclosure. Video encoder20 may perform intra and inter coding of video blocks within videoslices. Intra coding relies on spatial prediction to reduce or removespatial redundancy in video within a given video frame or picture. Intercoding relies on temporal prediction to reduce or remove temporalredundancy in video within adjacent frames or pictures of a videosequence. Intra prediction mode (I mode) may refer to any of severalspatial based compression modes.

In the example of FIG. 5, video encoder 20 includes video data memory40, prediction processing unit 41, decoded picture buffer (DPB) 64,summer 50, transform processing unit 52, quantization unit 54, andentropy encoding unit 56. Prediction processing unit 41 includespartition unit 35, motion estimation unit 42, motion compensation unit44, intra BC unit 48, and intra prediction processing unit 46. For videoblock reconstruction, video encoder 20 also includes inversequantization unit 58, inverse transform processing unit 60, and summer62. An in-loop filter (not pictured) may be positioned between summer 62and DPB 64.

In various examples, a fixed and/or programmable hardware unit of videoencoder 20 may be tasked to perform the techniques of this disclosure.Also, in some examples, the techniques of this disclosure may be dividedamong one or more of the illustrated fixed or programmable hardwareunits of video encoder 20 shown in FIG. 5, though other devices may alsoperform the techniques of this disclosure.

Video data memory 40 may store video data to be encoded by thecomponents of video encoder 20. The video data stored in video datamemory 40 may be obtained, for example, from video source 18. DPB 64 isa buffer that stores reference video data for use in encoding video databy video encoder 20 (e.g., in intra or inter coding modes, also referredto as intra or inter prediction coding modes). Video data memory 40 andDPB 64 may be formed by any of a variety of memory devices, such asdynamic random access memory (DRAM), including synchronous DRAM (SDRAM),magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types ofmemory devices. Video data memory 40 and DPB 64 may be provided by thesame memory device or separate memory devices. In various examples,video data memory 40 may be on-chip with other components of videoencoder 20, or off-chip relative to those components.

As shown in FIG. 5, video encoder 20 receives video data, and partitionunit 35 partitions the data into video blocks. This partitioning mayalso include partitioning into slices, tiles, or other larger units, aswells as video block partitioning, e.g., according to a quadtreestructure of LCUs and CUs. Video encoder 20 generally illustrates thecomponents that encode video blocks within a video slice to be encoded.The slice may be divided into multiple video blocks (and possibly intosets of video blocks referred to as tiles). Prediction processing unit41 may select one of a plurality of possible coding modes, such as oneof a plurality of intra coding modes or one of a plurality of intercoding modes, for the current video block based on error results (e.g.,coding rate and the level of distortion). Prediction processing unit 41may provide the resulting intra or inter coded block to summer 50 togenerate residual block data and to summer 62 to reconstruct the encodedblock for use as a reference picture.

Intra prediction processing unit 46 within prediction processing unit 41may perform intra predictive coding of the current video block relativeto one or more neighboring blocks in the same frame or slice as thecurrent block to be coded to provide spatial compression. Motionestimation unit 42 and motion compensation unit 44 within predictionprocessing unit 41 perform inter predictive coding of the current videoblock relative to one or more predictive blocks in one or more referencepictures to provide temporal compression.

Motion estimation unit 42 may be configured to determine the interprediction mode for a video slice according to a predetermined patternfor a video sequence. The predetermined pattern may designate videoslices in the sequence as P slices or B slices. Motion estimation unit42 and motion compensation unit 44 may be highly integrated, but areillustrated separately for conceptual purposes. Motion estimation,performed by motion estimation unit 42, is the process of generatingmotion vectors, which estimate motion for video blocks. A motion vector,for example, may indicate the displacement of a PU of a video blockwithin a current video frame or picture relative to a predictive blockwithin a reference picture.

Although video encoder 20 is shown with Intra BC unit 48, the techniquesof this disclosure may be performed by video encoders that do not encodevideo data using an Intra BC mode. Such video encoders may, for example,only encode video blocks in intra and inter modes, or may use othermodes, such as palette modes, not described in this disclosure. Intra BCunit 48 may determine vectors, e.g., block vectors, for Intra BC codingin a manner similar to the determination of motion vectors by motionestimation unit 42 for inter prediction, or may utilize motionestimation unit 42 to determine the block vector.

A predictive block is a block that is found to closely match the PU ofthe video block to be coded in terms of pixel difference, which may bedetermined by sum of absolute difference (SAD), sum of square difference(SSD), or other difference metrics. In some examples, video encoder 20may calculate values for sub-integer pixel positions of referencepictures stored in DPB 64. For example, video encoder 20 may interpolatevalues of one-quarter pixel positions, one-eighth pixel positions, orother fractional pixel positions of the reference picture. Therefore,motion estimation unit 42 may perform a motion search relative to thefull pixel positions and fractional pixel positions and output a motionvector with fractional pixel precision.

Motion estimation unit 42 calculates a motion vector for a PU of a videoblock in an inter coded slice by comparing the position of the PU to theposition of a predictive block of a reference picture. The referencepicture may be selected from a first reference picture list (List 0) ora second reference picture list (List 1), each of which identify one ormore reference pictures stored in DPB 64. Motion estimation unit 42sends the calculated motion vector to entropy encoding unit 56 andmotion compensation unit 44.

In some examples, intra BC unit 48 may generate vectors and fetchpredictive blocks in a manner similar to that described above withrespect to motion estimation unit 42 and motion compensation unit 44,but with the predictive blocks being in the same picture or frame as thecurrent block and with the vectors being referred to as block vectors asopposed to motion vectors. In other examples, intra BC unit 48 may usemotion estimation unit 42 and motion compensation unit 44, in whole orin part, to perform such functions for Intra BC prediction according tothe techniques described herein. In either case, for Intra BC, apredictive block may be a block that is found to closely match the blockto be coded, in terms of pixel difference, which may be determined bysum of absolute difference (SAD), sum of squared difference (SSD), orother difference metrics, and identification of the block may includecalculation of values for sub-integer pixel positions.

Motion compensation, performed by motion compensation unit 44, mayinvolve fetching or generating the predictive block based on the motionvector determined by motion estimation, possibly performinginterpolations to sub-pixel precision. Upon receiving the motion vectorfor the PU of the current video block, motion compensation unit 44 maylocate the predictive block to which the motion vector points in one ofthe reference picture lists. Video encoder 20 forms a residual videoblock by subtracting pixel values of the predictive block from the pixelvalues of the current video block being coded, forming pixel differencevalues. The pixel difference values form residual data for the block,and may include both luma and chroma difference components. Summer 50represents the component or components that perform this subtractionoperation. Motion compensation unit 44 may also generate syntax elementsassociated with the video blocks and the video slice for use by videodecoder 30 in decoding the video blocks of the video slice.

Whether the predictive video block is from the same picture according toIntra BC prediction, or a different picture according to interprediction, video encoder 20 may form a residual video block bysubtracting pixel values of the predictive block from the pixel valuesof the current video block being coded, forming pixel difference values.The pixel difference values form residual data for the block, and mayinclude both luma component differences and chroma componentdifferences. Summer 50 represents the component or components thatperform this subtraction operation. Intra BC unit 48 and/or motioncompensation unit 44 may also generate syntax elements associated withthe video blocks and the video slice for use by a video decoder, such asvideo decoder 30, in decoding the video blocks of the video slice. Thesyntax elements may include, for example, syntax elements defining thevector used to identify the predictive block, any flags indicating theprediction mode, or any other syntax described with respect to thetechniques of this disclosure.

Intra prediction processing unit 46 may intra-predict a current block,as an alternative to the inter-prediction performed by motion estimationunit 42 and motion compensation unit 44, or the Intra BC predictionperformed by intra BC unit 48, as described above. In particular, intraprediction processing unit 46 may determine an intra prediction mode,including an Intra BC mode, to use to encode a current block. In someexamples, intra prediction processing unit 46 may encode a current blockusing various intra prediction modes, e.g., during separate encodingpasses, and intra prediction processing unit 46 (or a mode select unit,in some examples) may select an appropriate intra prediction mode to usefrom the tested modes. As part of determining an intra prediction mode,intra prediction processing unit 46 may construct an MPM candidate listaccording to the techniques of this disclosure. Intra predictionprocessing unit 46 may select as the intra prediction mode for aparticular block either an intra prediction mode in the MPM candidatelist or a non-most probable mode not in the MPM candidate list.

Intra prediction processing unit 46 may, for example, calculaterate-distortion values using a rate-distortion analysis for the varioustested intra prediction modes, and select the intra prediction modehaving the best rate-distortion characteristics among the tested modes.Rate-distortion analysis generally determines an amount of distortion(or error) between an encoded block and an original, unencoded blockthat was encoded to produce the encoded block, as well as a bit rate(that is, a number of bits) used to produce the encoded block. Intraprediction processing unit 46 may calculate ratios from the distortionsand rates for the various encoded blocks to determine which intraprediction mode exhibits the best rate-distortion value for the block.

In any case, after selecting an intra prediction mode for a block, intraprediction processing unit 46 may provide information indicative of theselected intra prediction mode for the block to entropy encoding unit56. Entropy encoding unit 56 may encode the information indicating theselected intra prediction mode in accordance with the techniques of thisdisclosure. For blocks that are encoded using an intra prediction mode,entropy encoding unit 56 may, for example, select one or more contextsfor encoding the information indicating if the actual intra predictionmode is a mode in the MPM candidate list.

After prediction processing unit 41 generates the predictive block forthe current video block via either inter prediction or intra prediction,video encoder 20 forms a residual video block by subtracting thepredictive block from the current video block. The residual video datain the residual block may be included in one or more TUs and applied totransform processing unit 52. Transform processing unit 52 transformsthe residual video data into residual transform coefficients using atransform, such as a discrete cosine transform (DCT) or a conceptuallysimilar transform. Transform processing unit 52 may convert the residualvideo data from a pixel domain to a transform domain, such as afrequency domain.

Transform processing unit 52 may send the resulting transformcoefficients to quantization unit 54. Quantization unit 54 quantizes thetransform coefficients to further reduce bit rate. The quantizationprocess may reduce the bit depth associated with some or all of thecoefficients. The degree of quantization may be modified by adjusting aquantization parameter. In some examples, quantization unit 54 may thenperform a scan of the matrix including the quantized transformcoefficients. Alternatively, entropy encoding unit 56 may perform thescan.

Following quantization, entropy encoding unit 56 entropy encodes thequantized transform coefficients. Entropy encoding unit 56 also mayentropy encode various syntax elements. For example, entropy encodingunit 56 may perform CABAC, context adaptive variable length coding(CAVLC), syntax-based context-adaptive binary arithmetic coding (SBAC),probability interval partitioning entropy (PIPE) coding or anotherentropy encoding methodology or technique. Following the entropyencoding by entropy encoding unit 56, the encoded bitstream may betransmitted to video decoder 30, or archived for later transmission orretrieval by video decoder 30. Entropy encoding unit 56 may also entropyencode the motion vectors and the other syntax elements for the currentvideo slice being coded.

Inverse quantization unit 58 and inverse transform processing unit 60apply inverse quantization and inverse transformation, respectively, toreconstruct the residual block in the pixel domain for later use as areference block for prediction of other video blocks. Motioncompensation unit 44 and/or intra BC unit 48 may calculate a referenceblock by adding the residual block to a predictive block of one of thereference pictures within one of the reference picture lists. Motioncompensation unit 44 and/or intra BC unit 48 may also apply one or moreinterpolation filters to the reconstructed residual block to calculatesub-integer pixel values for use in motion estimation.

Summer 62 adds the reconstructed residual block to the motioncompensated prediction block produced by motion compensation unit 44 toproduce a reference block for storage in DPB 64. The reference block maybe used by intra BC unit 48, motion estimation unit 42 and motioncompensation unit 44 as a reference block to inter predict a block in asubsequent video frame or picture.

FIG. 6 is a block diagram illustrating an example video decoder 30 thatmay implement the techniques described in this disclosure. In theexample of FIG. 6, video decoder 30 includes video data memory 79,entropy decoding unit 80, prediction processing unit 81, inversequantization unit 86, inverse transform processing unit 88, summer 90,and DPB 92. Prediction processing unit 81 includes intra BC unit 85,motion compensation unit 82 and intra prediction processing unit 84.Video decoder 30 may, in some examples, perform a decoding passgenerally reciprocal to the encoding pass described with respect tovideo encoder 20 from FIG. 5.

Video data memory 79 may store video data, such as an encoded videobitstream, to be decoded by the components of video decoder 30. Thevideo data stored in video data memory 79 may be obtained, for example,from storage device 32, from a local video source, such as a camera, viawired or wireless network communication of video data, or by accessingphysical data storage media. Video data memory 79 may form a codedpicture buffer (CPB) that stores encoded video data from an encodedvideo bitstream. DPB 92 stores reference video data for use in decodingvideo data by video decoder 30 (e.g., in intra or inter coding modes,also referred to as intra or inter prediction coding modes). Video datamemory 79 and DPB 92 may be formed by any of a variety of memorydevices, such as DRAM, including SDRAM, MRAM, RRAM, or other types ofmemory devices. Video data memory 79 and DPB 92 may be provided by thesame memory device or separate memory devices. In various examples,video data memory 79 may be on-chip with other components of videodecoder 30, or off-chip relative to those components.

During the decoding process, video decoder 30 receives an encoded videobitstream that represents video blocks of an encoded video slice andassociated syntax elements from video encoder 20. Entropy decoding unit80 of video decoder 30 entropy decodes the bitstream to generatequantized coefficients, motion vectors, and other syntax elements.Entropy decoding unit 80 forwards the motion vectors and other syntaxelements to prediction processing unit 81. Video decoder 30 may receivethe syntax elements at the video slice level and/or the video blocklevel.

When the video slice is coded as an intra coded (I) slice or for intracoded blocks in other types of slices, intra prediction processing unit84 of prediction processing unit 81 may generate prediction data for avideo block of the current video slice based on a signaled intraprediction mode and data from previously decoded blocks of the currentframe or picture. Intra prediction processing unit 84 may be configuredto implement the techniques of this disclosure for performing intraprediction. More specifically, intra prediction processing unit 84 maybe configured to generate an MPM candidate list according to the MPMcandidate list construction techniques described herein. When the videoframe is coded as an inter coded (i.e., B or P) slice, motioncompensation unit 82 of prediction processing unit 81 producespredictive blocks for a video block of the current video slice based onthe motion vectors and other syntax elements received from entropydecoding unit 80. The predictive blocks may be produced from one of thereference pictures within one of the reference picture lists. Videodecoder 30 may construct the reference frame lists, List 0 and List 1,using default construction techniques based on reference pictures storedin DPB 92.

In other examples, when the video block is coded according to the IntraBC mode described herein, intra BC unit 85 of prediction processing unit81 produces predictive blocks for the current video block based on blockvectors and other syntax elements received from entropy decoding unit80. The predictive blocks may be within a reconstructed region withinthe same picture as the current video block defined by video encoder 20,and retrieved from DPB 92. Although video decoder 30 is shown with IntraBC unit 85, the techniques of this disclosure may be performed by videodecoders that do not decode video data using an Intra BC mode. Suchvideo decoders may, for example, only decode video blocks in intra andinter modes, or may use other modes, such as palette modes, notdescribed in this disclosure.

Motion compensation unit 82 and/or intra BC unit 85 may determineprediction information for a video block of the current video slice byparsing the motion vectors and other syntax elements, and use theprediction information to produce the predictive blocks for the currentvideo block being decoded. For example, motion compensation unit 82 usessome of the received syntax elements to determine a prediction mode(e.g., intra or inter prediction) used to code the video blocks of thevideo slice, an inter prediction slice type (e.g., B slice or P slice),construction information for one or more of the reference picture listsfor the slice, motion vectors for each inter encoded video block of theslice, inter prediction status for each inter coded video block of theslice, and other information to decode the video blocks in the currentvideo slice.

Similarly, intra BC unit 85 may use some of the received syntaxelements, e.g., a flag, to determine that the current video block waspredicted using the Intra BC mode, construction information indicatingwhich video blocks of the picture are within the reconstructed regionand should be stored in DPB 92, block vectors for each Intra BCpredicted video block of the slice, Intra BC prediction status for eachIntra BC predicted video block of the slice, and other information todecode the video blocks in the current video slice.

Motion compensation unit 82 may also perform interpolation based oninterpolation filters. Motion compensation unit 82 may use interpolationfilters as used by video encoder 20 during encoding of the video blocksto calculate interpolated values for sub-integer pixels of referenceblocks. In this case, motion compensation unit 82 may determine theinterpolation filters used by video encoder 20 from the received syntaxelements and use the interpolation filters to produce predictive blocks.Video decoder 30 may be configured to decode blocks coded in merge modeand/or AMVP mode, in which case prediction processing unit 81 may beconfigured to assemble the same candidate lists assembled by videoencoder 20.

Inverse quantization unit 86 inverse quantizes, i.e., de-quantizes, thequantized transform coefficients provided in the bitstream and decodedby entropy decoding unit 80. The inverse quantization process mayinclude use of a quantization parameter calculated by video encoder 20for each video block in the video slice to determine a degree ofquantization and, likewise, a degree of inverse quantization that shouldbe applied. Inverse transform processing unit 88 applies an inversetransform, e.g., an inverse DCT, an inverse integer transform, or aconceptually similar inverse transform process, to the transformcoefficients in order to produce residual blocks in the pixel domain.

After motion compensation unit 82 or intra BC unit 85 generates thepredictive block for the current video block based on the vectors andother syntax elements, video decoder 30 forms a decoded video block bysumming the residual blocks from inverse transform processing unit 88with the corresponding predictive blocks generated by motioncompensation unit 82 and intra BC unit 85. Summer 90 represents thecomponent or components that perform this summation operation to producereconstructed video blocks.

Summer 90 represents the component or components that perform thissummation operation. An in-loop filter (not pictured) may be positionedbetween summer 90 and DPB 92. The decoded video blocks in a given frameor picture are then stored in DPB 92, which stores reference picturesused for subsequent motion compensation. DPB 92, or a memory deviceseparate from DPB 92, may also store decoded video for laterpresentation on a display device, such as display device 34 of FIG. 1.

FIGS. 7A and 7B show examples of a CABAC process at a bin n. In example100 of FIG. 7A, at bin n the range at bin 2 includes the RangeMPS andRangeLPS given by the probability of the least probable symbol (LPS)(p_(σ)) given a certain context state (σ). Example 100 shows the updateof the range at bin n+1 when the value of bin n is equal to the mostprobable symbol (MPS). In this example, the low stays the same, but thevalue of the range at bin n+1 is reduced to the value of RangeMPS at binn. Example 102 of FIG. 7B shows the update of the range at bin n+1 whenthe value of bin n is not equal to the MPS (i.e., equal to the LPS). Inthis example, the low is moved to the lower range value of RangeLPS atbin n. In addition, the value of the range at bin n+1 is reduced to thevalue of RangeLPS at bin n.

In one example of the HEVC video coding process, range is expressed with9 bits and the low with 10 bits. There is a renormalization process tomaintain the range and low values at sufficient precision. Therenormalization occurs whenever the range is less than 256. Therefore,the range is always equal or larger than 256 after renormalization.Depending on the values of range and low, the binary arithmetic coder(BAC) outputs to the bitstream, a ‘0,’ or a ‘1,’ or updates an internalvariable (called BO: bits-outstanding) to keep for future outputs. FIG.8 shows examples of BAC output depending on the range. For example, a‘1’ is output to the bitstream when the range and low are above acertain threshold (e.g., 512). A ‘0’ is output to the bitstream when therange and low are below a certain threshold (e.g., 512). Nothing isoutput to the bitstream when the range and lower are between certainthresholds. Instead, the BO value is incremented and the next bin isencoded.

In the CABAC context model of H.264/AVC and in some examples of HEVC,there are 128 states. There are 64 possible LPS probabilities (denotedby state σ) that can be from 0 to 63. Each MPS can be zero or one. Assuch, the 128 states are 64 state probabilities times the 2 possiblevalues for MPS (0 or 1). Therefore, the state can be indexed with 7bits.

To reduce the computation of deriving LPS ranges (rangeLPS_(σ)), resultsfor all cases may pre-calculated and stored as approximations in alook-up table. Therefore, the LPS range can be obtained without anymultiplication by using a simple table lookup. Avoiding multiplicationcan be important for some devices or applications, since this operationmay cause significant latency in many hardware architectures.

A 4-column pre-calculated LPS range table may be used instead of themultiplication. The range is divided into four segments. The segmentindex can be derived by the question (range>>6)&3. In effect, thesegment index is derived by shifting and dropping bits from the actualrange. The following Table 1 shows the possible ranges and theircorresponding indexes.

TABLE 1 Range Index Range 256-319 320-383 384-447 448-511 (range>>6) & 30 1 2 3

The LPS range table has then 64 entries (one for each probability state)times 4 (one for each range index). Each entry is the Range LPS, thatis, the value of multiplying the range times the LPS probability. Anexample of part of this table is shown in the following Table 2. Table 2depicts probability states 9-12. In one proposal for HEVC, theprobability states may range from 0-63.

TABLE 2 RangeLPS RangeLPS Prob State (σ) Index 0 Index Index 2 Index 3 .. . . . . . . . . . . . . .  9 90 110 130 150 10 85 104 123 142 11 81 99117 135 12 77 94 111 128 . . . . . . . . . . . . . . .

In each segment (i.e., range value), the LPS range of each probabilitystate_(σ) is pre-defined. In other words, the LPS range of a probabilitystate_(σ) is quantized into four values (i.e., one value for each rangeindex). The specific LPS range used at a given point depends on whichsegment the range belongs to. The number of possible LPS ranges used inthe table is a trade-off between the number of table columns (i.e., thenumber of possible LPS range values) and the LPS range precision.Generally speaking, more columns results in smaller quantization errorsof LPS range values, but also increases the need for more memory tostore the table. Fewer columns increases quantization errors, but alsoreduces the memory needed to store the table.

As described above, each LPS probability state has a correspondingprobability. The probability p for each state is derived as follows:p _(σ) =αp _(σ-1)where the state σ is from 0 to 63. The constant α represents the amountof probability change between each context state. In one example,α=0.9493, or, more precisely, α=(0.01875/0.5)^(1/63). The probability atstate σ=0 is equal to 0.5 (i.e., p₀=1/2). That is, at context state 0,the LPS and MPS are equally probable. The probability at each successivestate is derived by multiplying the previous state by α. As such, theprobability of the LPS occurring at context state α=1 isp₀*0.9493(0.5*0.9493=0.47465). As such, as the index of state αincreases, the probability of the LPS occurring goes down.

CABAC is adaptive because the probability states are updated in order tofollow the signal statistics (i.e., the values of previously codedbins). The update process is as follows. For a given probability state,the update depends on the state index and the value of the encodedsymbol identified either as an LPS or an MPS. As a result of theupdating process, a new probability state is derived, which consists ofa potentially modified LPS probability estimate and, if necessary, amodified MPS value.

In the event of a bin value equaling the MPS, a given state index may beincremented by 1. This is for all states except when an MPS occurs atstate index 62, where the LPS probability is already at its minimum (orequivalently, the maximum MPS probability is reached). In this case, thestate index 62 remains fixed until an LPS is seen, or the last bin valueis encoded (state 63 is used for the special case of the last binvalue). When an LPS occurs, the state index is changed by decrementingthe state index by a certain amount, as shown in the equation below.This rule applies in general to each occurrence of a LPS with thefollowing exception. Assuming a LPS has been encoded at the state withindex σ=0, which corresponds to the equi-probable case, the state indexremains fixed, but the MPS value will be toggled such that the value ofthe LPS and MPS will be interchanged. In all other cases, no matterwhich symbol has been encoded, the MPS value will not be altered. Thederivation of the transition rules for the LPS probability is based onthe following relation between a given LPS probability p_(old) and itsupdated counterpart p_(new):p _(new)=max(αp _(old) ,p ₆₂) if a MPS occursp _(new)=(1−α)+αp _(old) if a LPS occurs

With regard to a practical implementation of the probability estimationprocess in CABAC, it is important to note that all transition rules maybe realized by at most two tables each having 63 entries of 6-bitunsigned integer values. In some examples, state transitions may bedetermined with a single table TransIdxLPS, which determines, for agiven state index σ, the new updated state index TransIdxLPS[σ] in casean LPS has been observed. The MPS-driven transitions can be obtained bya simple (saturated) increment of the state index by the fixed value of1, resulting in an updated state index min(σ+1, 62). Table 3 below is anexample of a partial TransIdxLPS table.

TABLE 3 TransIdxLPS Prob State (σ) New State TransIdxLPS [σ] . . . . . . 9 6 10 8 11 8 12 8 . . . . . .

One problem with previous BAC approaches (e.g., the BAC approach used inH.264/AVC), is that the tables RangeLPS and TransIdxLPS are tuned forlow resolution videos, (i.e., common intermediate format (CIF) andquarter-CIF (QCIF) videos). Currently, a large amount of video contentis high definition (HD) and, in some cases, greater than HD. Videocontent that is HD or greater than HD resolution has differentstatistics than the 10-year-old QCIF sequences used to developH.264/AVC.

As such, tables RangeLPS and TransIdxLPS from H.264/AVC may causeadaptation between states in a manner that is too quick. That is, thetransitions between probability states, especially when an LPS occurs,can be too great for the smoother, higher resolution content of HDvideo. Thus, the probability models used according to conventionaltechniques are not as accurate for HD and extra-HD content. In addition,as HD video content includes a greater range of pixel values, theH.264/AVC tables do not include enough entries to account for the moreextreme values that may be present in HD content.

As such, there is a need for the RangeLPS and TransIdxLPS tables to bemodified to account for the characteristics of this new content. Thisalso implies that BAC should be different in at least two aspects. Onedifference is that BAC processes should use tables that allow for aslower adaptation process. Another difference is that BAC processesshould account for more extreme cases (i.e., skewed probabilities).

The current RangeLPS and TransIdxLPS tables can be modified to achievethese goals by simply including more probability states and ranges.However, this solution incurs a substantial increase in the sizes of thetables. Slower adaptation may be achieved by using a parameter α closerto 1 than the currently used parameter α (e.g., α=0.9493). However,using a larger value of α causes the probabilities to tend to 0 moreslowly, and as such, more states are needed. In addition, to achieveslower adaptation, it may be beneficial if the lowest possibleprobability is much lower than the currently used lowest probability. Assuch, even more states may be needed to reach that very low probabilityvalue.

In view of the foregoing problems, this disclosure proposes techniquesto modify BAC so as to attain slower adaptation and more skewedprobabilities while keeping the table sizes (e.g., the RangeLPS andTransIdxLPS tables) at a practical level. In other words, thisdisclosure describes techniques to achieve slower adaptation and moreextreme probabilities (i.e., probabilities closer to 0 and 1) whileusing relatively small-sized tables.

The techniques described in this disclosure may use more probabilitystates, e.g., more probability states than used in BAC with H.264/AVC orHEVC. In this case, the TransIdxLPS table can obtain slower adaptationand lower probabilities. In one example, the techniques described inthis disclosure may use 128 probability states instead of 64. Thisincreases the table TransIdxLPS by 64 entries (i.e., 128 entries insteadof 64). This increase allows for slower adaptation and lower minimalprobability. As one example, by setting the parameter α=0.9689, thedifferences between contiguous probabilities become smaller.Additionally, the lowest minimum probability goes down to 0.009, whichis around one-half of the H.264/AVC case (i.e., 0.01875). Other numbersof states and α values are also possible, though, in general, the numberof states may be increased and the value of a may be closer to 1 thanthe H.264/AVC case of α=0.9493.

Another parameter that might be modified to improve HD or extra-HDcoding is the parameter p₀. The value of p₀ generally indicates themaximum probability for the LPS. The reason to consider this possibilityis that having a lower p₀ means that the minimal probability alsodecreases. The value of p₀ is set to 0.5 in the conventional BACprocess. This disclosure proposes to allow for other values for p₀.Having other values of p₀ lower than 0.5 allows for smoother transitionsat state 0 when the MPS/LPS swap occurs. In one example, p₀ may be equalto 0.493, although many other examples could also be used.

Usually, each probability state has its own entry in the RangeLPS table.The table size may be represented as:# probability states×# quantized range indexeswhich is 64×4=256 bytes in some proposals for HEVC. Since the number ofstates would increase in examples of this disclosure (doubled in theexample above), the RangeLPS table size may be 128×4=512 bytes. To avoidthis increase in the RangeLPS table size, however, this disclosurefurther proposes to map the probability states indexes to a lower size(i.e., a few number of indexes) to index the RangeLPS size. In otherwords, this disclosure proposes to decouple the state transition processfrom the range computation process. This means, in the current example,that there is a map for the states to range computation. Video encoder20 and/or video decoder 30 may be configured to map an index indicatingthe determined probability state to one of a plurality of groupedindexes (e.g., grouped index for a RangeLPS table), with at least one ofthe grouped indexes representing at least two of the plurality ofprobability states. As such, the RangeLPS table (or other BAC tables)may use fewer indexes than there are probability states.

In one example of the disclosure, the probability state number may bedivided by two to generate a new index to use as an entry for theRangeLPS table. In this case, the 128 probability states are reduced to64 entries. Consequently, the RangeLPS table can keep the current sizeas used in H.264/AVC. Therefore, instead of using the probability stateσ to index the entry in the range LPS table, the techniques described inthis disclosure employ (σ>>1), that is, the state σ is divided by twoand rounded to the lower integer for use as a grouped index into theRangeLPS table. The division can be by a larger number if the RangeLPStable is desired to be smaller for a given implementation, or if thenumber of states is larger (e.g., 256 probability states). In thiscontext, each grouped index represents two probability states. In otherexamples of the disclosure, the grouped indexes may represent two ormore probability states.

From an optimal entropy point of view, the grouping of the states forthe RangeLPS table by using the division or right bit-shift operationmay be beneficial, but may not always be the optimal technique. Theoptimal grouping may depend on several factors, including the number ofstates and the parameter α, among others. The most desirable (andpossibly optimal) grouping might not be a straightforward operation likethe bit-shift operation. In general, the grouping can be described witha table, going from the total number of probability states to a reducednumber of probability states (i.e., grouped states). In another example,this disclosure proposes to use this kind of table. This approach wouldenhance performance (compared to the division or right shifting), at thecost of additional memory. As such, this example is a trade-off betweenmemory and performance, favoring better performance over the linearmapping example (i.e., the division or right shifting).

Hence, although a linear mapping of probability states to entries in theRangeLPS table may be used, it may be desirable to provide a nonlinearmapping. For example, the probability states may be mapped according toa logarithmic mapping. A logarithmic mapping may be achieved, in someexamples, using piecewise linear mapping techniques. In general, such amapping may be defined using a table, such as a precomputed mappingtable.

In general, the techniques described in this disclosure may beperformed, in some examples, by a method or device for entropy codingvideo data. The method may include determining a probability state ofsymbols in a binary arithmetic coding process, where the probabilitystate may be one of a plurality of probability states, and mapping anindex indicating the determined probability state to one of a pluralityof grouped indexes, where at least one of the grouped indexes representsat least two of the plurality of probability states, and where each ofthe grouped indexes points to a range for a lowest probability symbol ina table.

In some examples, the number of probability states may be greater than64. For example, the number of probability states may be 128. In someexamples, the number of grouped indexes used as an input into theRangeLPS table is 64. In particular, the number of probability statesmay be 128 and the number of grouped indexes used as an input into theRangeLPS table may be 64. A symbol may be coded based on the groupedindexes, e.g., according to a table based on the probability stateindex, or according to a mathematical operation based on the index. Thedetermined probability state maps to one of a plurality of indexesaccording to a table, or according to a mathematical operation. Themapping may be linear or nonlinear. For example, the mapping may beperformed according to a divide-by-two operation. In some examples, themapping may be a logarithmic mapping. In some examples, a piecewiselinear mapping may be used to define a logarithmic mapping. In someexamples, the value p₀ of the maximum probability for the LPS may beless than 0.5.

The techniques described in this disclosure may be performed, forexample, within a video encoder, video decoder, or combined videoencoder-decoder (CODEC). In particular, such techniques may be performedin an entropy encoding unit of a video encoder and/or an entropydecoding unit of a video decoder. The techniques may be performed, forexample, within a CABAC process, which may be configured to supportvideo coding, such as video coding according to aspects of the HEVCstandard Entropy encoding and decoding units may apply coding processesin a reciprocal or inverse manner, e.g., to encode or decode any of avariety of video data, such as quantized transform coefficientsassociated with residual video data, motion vector information, syntaxelements, and other types of information that may be useful in a videoencoding and/or video decoding process.

FIG. 9 is a block diagram of an example entropy encoding unit 56 thatmay be configured to perform CABAC in accordance with the techniques ofthis disclosure. A syntax element 118 is input into the entropy encodingunit 56. If the syntax element is already a binary-value syntax element(i.e., a syntax element that only has a value of 0 and 1), the step ofbinarization may be skipped. If the syntax element is a non-binaryvalued syntax element (e.g., a syntax element represented by multiplebits, such as transform coefficient levels), the non-binary valuedsyntax element is binarized by binarizer 120. Binarizer 120 performs amapping of the non-binary valued syntax element into a sequence ofbinary decisions. These binary decisions are often called “bins.” Forexample, for transform coefficient levels, the value of the level may bebroken down into successive bins, each bin indicating whether or not theabsolute value of coefficient level is greater than some value. Forexample, bin 0 (sometimes called a significance flag) indicates if theabsolute value of the transform coefficient level is greater than 0 ornot. Bin 1 indicates if the absolute value of the transform coefficientlevel is greater than 1 or not, and so on. A unique mapping may bedeveloped for each non-binary valued syntax element.

Each bin produced by binarizer 120 is fed to the binary arithmeticcoding side of entropy encoding unit 56. That is, for a predeterminedset of non-binary valued syntax elements, each bin type (e.g., bin 0) iscoded before the next bin type (e.g., bin 1). Coding may be performed ineither regular mode or bypass mode. In bypass mode, bypass coding engine126 performs arithmetic coding using a fixed probability model, forexample, using Golomb-Rice or exponential Golomb coding. Bypass mode isgenerally used for more predictable syntax elements.

Coding in regular mode involves performing CABAC. Regular mode CABAC isfor coding bin values where the probability of a value of a bin ispredictable given the values of previously coded bins. The probabilityof a bin being an LPS is determined by context modeler 122. Contextmodeler 122 outputs the bin value and the context model (e.g., theprobability state σ). The context model may be an initial context modelfor a series of bins, or may be determined based on the coded values ofpreviously coded bins. As described above, the context modeler mayupdate the state based on whether or not the previously-coded bin was anMPS or an LPS.

After the context model and probability state σ are determined bycontext modeler 122, regular coding engine 124 performs BAC on the binvalue. According to the techniques of this disclosure, regular codingengine 124 performs BAC using TransIdxLPS table 130 that includes morethan 64 probability states σ. In one example, the number of probabilitystates is 128. TransIdxLPS is used to determine which probability stateis used for a next bin (bin n+1) when the previous bin (bin n) is anLPS. Regular coding engine 124 may also use a RangeLPS table 128 todetermine the range value for an LPS given a particular probabilitystate σ. However, according to the techniques of this disclosure, ratherthan using all possible probability states σ of the TransIdxLPS table130, the probability state indexes σ are mapped to grouped indexes foruse in the RangeLPS table. That is, each index into the RangeLPS table128 may represent two or more of the total number of probability states.The mapping of probability state index σ to grouped indexes may belinear (e.g., by dividing by two), or may be non-linear (e.g., alogarithmic function or mapping table).

In other examples of the disclosure, the difference between successiveprobability states may be made smaller by setting the parameter α to begreater than 0.9493. In one example, α=0.9689. In another example of thedisclosure, the highest probability (p₀) of an LPS occurring may be setto be lower than 0.5. In one example, p₀ may be equal to 0.493.

In accordance with one or more techniques of this disclosure, as opposedto using the same value of a variable used to update a probability statein a binary arithmetic coding process (e.g., one or more of a windowsize, a scaling factor (α), and a probability updating speed), entropyencoding unit 56 may use different values of the variable for differentcontext models and/or different syntax elements. For instance, entropyencoding unit 56 may determine, for a context model of a plurality ofcontext models, a value of a variable used to update a probability statein a binary arithmetic coding process, and update the probability statebased on the determined value.

Returning to FIG. 4, in some cases, the entropy encoding unit 56 oranother unit of video encoder 20 may be configured to perform othercoding functions, in addition to entropy coding. For example, entropyencoding unit 56 may be configured to determine coded block pattern(CBP) values for CU's and PU's. Also, in some cases, entropy encodingunit 56 may perform run length coding of coefficients. In addition,entropy encoding unit 56, or other processing units, also may code otherdata, such as the values of a quantization matrix.

As discussed above, inverse quantization unit 58 and inverse transformprocessing unit 60 apply inverse quantization and inversetransformation, respectively, to reconstruct the residual block in thepixel domain, e.g., for later use as a reference block. Motioncompensation unit 44 may calculate a reference block by adding theresidual block to a predictive block of one of the frames of DPB 64.Motion compensation unit 44 may also apply one or more interpolationfilters to the reconstructed residual block to calculate sub-integerpixel values for use in motion estimation. Summer 62 adds thereconstructed residual block to the motion compensated prediction blockproduced by motion compensation unit 44 to produce a reconstructed videoblock for storage in DPB 64. The reconstructed video block may be usedby motion estimation unit 42 and motion compensation unit 44 as areference block to inter-code a block in a subsequent video frame.

FIG. 10 is a block diagram of an example entropy decoding unit 80 thatmay be configured to perform CABAC in accordance with the techniques ofthis disclosure. The entropy decoding unit 80 of FIG. 10 performs CABACin an inverse manner as that of entropy encoding unit 56 described inFIG. 5. Coded bits from bitstream 218 are input into entropy decodingunit 80. The coded bits are fed to either context modeler 220 or bypasscoding engine 222 based on whether or not the coded bits were entropycoded using bypass mode or regular mode. If the coded bits were coded inbypass mode, bypass decoding engine 222 may, for example, useGolomb-Rice or exponential Golomb decoding to retrieve the binary-valuedsyntax elements or bins of non-binary syntax elements.

If the coded bits were coded in regular mode, context modeler 220 maydetermine a probability model for the coded bits and regular decodingengine 224 may decode the coded bits to produce bins of non-binaryvalued syntax elements (or the syntax elements themselves ifbinary-valued). After the context model and probability state σ isdetermined by context modeler 220, regular decoding engine 224 performsBAC on the bin value. According to the techniques of this disclosure,regular decoding engine 224 performs BAC using TransIdxLPS table 228that includes more than 64 probability states σ. In one example, thenumber of probability states is 128, although other numbers ofprobability states could be defined, consistent with the techniques ofthis disclosure. TransIdxLPS table 228 is used to determine whichprobability state is used for a next bin (bin n+1) when the previous bin(bin n) is an LPS. Regular decoding engine 224 may also use a RangeLPStable 226 to determine the range value for an LPS given a particularprobability state σ. However, according to the techniques of thisdisclosure, rather than using all possible probability states σ of theTransIdxLPS table 228, the probability state indexes σ are mapped togrouped indexes for use in RangeLPS table 226. That is, each index intoRangeLPS table 226 may represent two or more of the total number ofprobability states. The mapping of probability state index σ to groupedindexes may be linear (e.g., by dividing by two), or may be non-linear(e.g., a logarithmic function or mapping table).

In other examples of the disclosure, the difference between successiveprobability states may be made smaller by setting the parameter α to begreater than 0.9493. In one example, α=0.9689. In another example of thedisclosure, the highest probability (p₀) of an LPS occurring may be setto be lower than 0.5. In one example, p₀ may be equal to 0.493.

After the bins are decoded by regular decoding engine 224, a reversebinarizer 230 may perform a reverse mapping to convert the bins backinto the values of the non-binary valued syntax elements.

FIG. 11 is a flow diagram illustrating an example video coding techniquedescribed in this disclosure. The techniques of FIG. 11 will bedescribed with reference to a generic video coder, such as but notlimited to video encoder 20 or video decoder 30. In the example of FIG.11 the video coder determines a context for a first syntax elementindicating whether there is at least one non-zero transform coefficientlevel associated with a current block based on already coded informationfor the current (250).

The already coded information may, for example, include one or more of acoding mode of the block, such as whether the block is coded using anintra coding mode or an inter coding mode. The block may include a lumablock, and the value for the first syntax element may indicate whetherthere is at least one non-zero transform coefficient level associatedwith the luma block. The block may include a chroma block, and the valuefor the first syntax element may indicate whether there is at least onenon-zero transform coefficient level associated with the chroma block.In some examples, the block may include a chroma block and a luma block,and the value for the first syntax element may indicate whether there isat least one non-zero transform coefficient level associated with atleast one of the chroma block or the luma block. In some examples, thealready coded information may include a size or shape of the block.

The video coder codes the first syntax element based on the determinedcontext (252). To code the first syntax element based on the determinedcontext, the video coder may, for example, perform CABAC operation onthe first syntax element. In examples where the video coder is a videoencoder, then as part of coding the first syntax element based on thedetermined context, the video encoder may output a bitstream of encodedvideo data that includes the first syntax element. In examples where thevideo coder is a video decoder, then as part of coding the first syntaxelement based on the determined context, the video decoder may receive abitstream of encoded video data that includes the first syntax elementand determine the value for the first syntax element.

In some examples, the video coder may determine a context for a mergeflag for a second block based on the value of the first syntax element.The second block may, for example, be a neighboring block of the firstblock and be coded after the first block.

FIG. 12 is a flow diagram illustrating an example video coding techniquedescribed in this disclosure. The techniques of FIG. 12 will bedescribed with reference to a generic video coder, such as but notlimited to video encoder 20 or video decoder 30. In the example of FIG.12 the video coder codes a first syntax element indicating whether thereis at least one non-zero transform coefficient level associated with afirst block of video data (260).

The video coder determines a context for a second syntax elementindicating coding mode information for a second block based on the valuefor the first syntax element (262). The video coder may, for example,determine the context for the second syntax element indicating thecoding mode information for the second block from at least two availablecontexts. The second syntax element may, for example, be a merge flagfor the second block or a syntax element indicating a prediction modefor the second block. In some examples, the first block and the secondblock may be spatially neighboring blocks. In some examples, the firstblock may be in a reference picture and the second block in a currentpicture, and the first block may be co-located relative to the secondblock. In some examples, first block may in a reference picture and thesecond block in a current picture, and the first block may neighbor ablock that is co-located relative to the second block. The first blockand the second block may either both be luma blocks or both be chromablocks.

The video codes the second syntax element based on the determinedcontext (264). To code the second syntax element based on the determinedcontext, the video coder may, for example, perform CABAC operation onthe second syntax element. In examples where the video coder is a videoencoder, then as part of coding the second syntax element based on thedetermined context, the video encoder may output a bitstream of encodedvideo data that includes the second syntax element. In examples wherethe video coder is a video decoder, then as part of coding the firstsyntax element based on the determined context, the video decoder mayreceive a bitstream of encoded video data that includes the secondsyntax element and determine the value for the second syntax element.

In one or more examples, the functions described may be implemented inhardware, software, firmware, or any combination thereof. If implementedin software, the functions may be stored on or transmitted over, as oneor more instructions or code, a computer-readable medium and executed bya hardware-based processing unit. Computer-readable media may includecomputer-readable storage media, which corresponds to a tangible mediumsuch as data storage media, or communication media including any mediumthat facilitates transfer of a computer program from one place toanother, e.g., according to a communication protocol. In this manner,computer-readable media generally may correspond to (1) tangiblecomputer-readable storage media which is non-transitory or (2) acommunication medium such as a signal or carrier wave. Data storagemedia may be any available media that can be accessed by one or morecomputers or one or more processors to retrieve instructions, codeand/or data structures for implementation of the techniques described inthis disclosure. A computer program product may include acomputer-readable medium.

By way of example, and not limitation, such computer-readable storagemedia may include one or more of RAM, ROM, EEPROM, CD-ROM or otheroptical disk storage, magnetic disk storage, or other magnetic storagedevices, flash memory, or any other medium that can be used to storedesired program code in the form of instructions or data structures andthat can be accessed by a computer. Also, any connection is properlytermed a computer-readable medium. For example, if instructions aretransmitted from a website, server, or other remote source using acoaxial cable, fiber optic cable, twisted pair, digital subscriber line(DSL), or wireless technologies such as infrared, radio, and microwave,then the coaxial cable, fiber optic cable, twisted pair, DSL, orwireless technologies such as infrared, radio, and microwave areincluded in the definition of medium. It should be understood, however,that computer-readable storage media and data storage media do notinclude connections, carrier waves, signals, or other transient media,but are instead directed to non-transient, tangible storage media. Diskand disc, as used herein, includes compact disc (CD), laser disc,optical disc, digital versatile disc (DVD), floppy disk and Blu-raydisc, where disks usually reproduce data magnetically, while discsreproduce data optically with lasers. Combinations of the above shouldalso be included within the scope of computer-readable media.

Instructions may be executed by one or more processors, such as one ormore digital signal processors (DSPs), general purpose microprocessors,application specific integrated circuits (ASICs), field programmablelogic arrays (FPGAs), or other equivalent integrated or discrete logiccircuitry. Accordingly, the term “processor,” as used herein may referto any of the foregoing structure or any other structure suitable forimplementation of the techniques described herein. In addition, in someaspects, the functionality described herein may be provided withindedicated hardware and/or software modules configured for encoding anddecoding, or incorporated in a combined codec. Also, the techniquescould be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide varietyof devices or apparatuses, including a wireless handset, an integratedcircuit (IC) or a set of ICs (e.g., a chip set). Various components,modules, or units are described in this disclosure to emphasizefunctional aspects of devices configured to perform the disclosedtechniques, but do not necessarily require realization by differenthardware units. Rather, as described above, various units may becombined in a codec hardware unit or provided by a collection ofinteroperative hardware units, including one or more processors asdescribed above, in conjunction with suitable software and/or firmware.

Various examples have been described. These and other examples arewithin the scope of the following claims.

What is claimed is:
 1. A method of coding video data, the methodcomprising; coding a first syntax element, wherein a value for the firstsyntax element indicates whether there is at least one non-zerotransform coefficient level associated with a transform unit of a firstcoding unit; determining a context for a second syntax element based onthe value for the first syntax element, wherein the second syntaxelement indicates coding mode information for a prediction unit of asecond coding unit; and coding the second syntax element based on thedetermined context.
 2. The method of claim 1, wherein the second syntaxelement comprises a merge flag for the second coding unit, the methodfurther comprising: coding a third syntax element, wherein a value forthe third syntax element indicates whether there is at least onenon-zero transform coefficient level associated with a transform unit ofa third coding unit, wherein the first coding unit is a top neighboringcoding unit of the second coding unit and the third coding unit is aleft neighboring coding unit of the second coding unit; adding the valueof the first syntax element to the value of the third syntax element todetermine a context index; and wherein determining the context for thesecond syntax element based on the value for the first syntax elementcomprises determining the context for the second syntax element based onthe context index.
 3. The method of claim 1, wherein the second syntaxelement indicates a prediction mode for the second coding unit.
 4. Themethod of claim 1, wherein the first coding unit and the second codingunit are spatially neighboring coding units.
 5. The method of claim 1,wherein the first coding unit is in a reference picture and the secondcoding unit is in a current picture, and the first coding unit isco-located relative to the second coding unit.
 6. The method of claim 1,wherein the first coding unit is in a reference picture and the secondcoding unit is in a current picture, and wherein the first coding unitneighbors a coding unit that is co-located relative to the second codingunit.
 7. The method of claim 1, wherein the first coding unit and thesecond coding unit comprise luma blocks.
 8. The method of claim 1,wherein the first coding unit and the second coding unit comprise chromablocks.
 9. The method of claim 1, wherein coding the second syntaxelement based on the determined context comprises performing acontext-adaptive binary arithmetic coding (CABAC) operation on thesecond syntax element.
 10. The method of claim 1, wherein codingcomprises encoding, and wherein coding the second syntax element basedon the determined context comprises outputting a bitstream of encodedvideo data comprising the second syntax element.
 11. The method of claim1, wherein coding comprises decoding, and wherein coding the secondsyntax element based on the determined context comprises receiving abitstream of encoded video data comprising the second syntax element anddetermining the value for the second syntax element.
 12. A device forcoding video data, the device comprising: a memory; and one or moreprocessors configured to: code a first syntax element, wherein a valuefor the first syntax element indicates whether there is at least onenon-zero transform coefficient level associated with a transform unit ofa first coding unit; determine a context for a second syntax elementbased on the value for the first syntax element, wherein the secondsyntax element indicates coding mode information for a prediction unitof a second coding unit; and code the second syntax element based on thedetermined context.
 13. The device of claim 12, wherein the secondsyntax element comprises a merge flag for the second coding unit, andwherein the one or more processors are further configured to: code athird syntax element, wherein a value for the third syntax elementindicates whether there is at least one non-zero transform coefficientlevel associated with a transform unit of a third coding unit, whereinthe first coding unit is a top neighboring coding unit of the secondcoding unit and the third coding unit is a left neighboring coding unitof the second coding unit; add the value of the first syntax element tothe value of the third syntax element to determine a context index; anddetermine the context for the second syntax element based on the valuefor the first syntax element by determining the context for the secondsyntax element based on the context index.
 14. The device of claim 12,wherein the second syntax element indicates a prediction mode for thesecond coding unit.
 15. The device of claim 12, wherein the first codingunit and the second coding unit are spatially neighboring coding units.16. The device of claim 12, wherein the first coding unit is in areference picture and the second coding unit is in a current picture,and the first coding unit is co-located relative to the second codingunit.
 17. The device of claim 12, wherein the first coding unit is in areference picture and the second coding unit is in a current picture,and wherein the first coding unit neighbors a coding unit that isco-located relative to the second coding unit.
 18. The device of claim12, wherein the first coding unit and the second coding unit compriseluma blocks.
 19. The device of claim 12, wherein the first coding unitand the second coding unit comprise chroma blocks.
 20. The device ofclaim 12, wherein to code the second syntax element based on thedetermined context, the one or more processors are configured to performa context-adaptive binary arithmetic coding (CABAC) operation on thesecond syntax element.
 21. The device of claim 12, wherein the devicecomprises a video encoder, and wherein to code the second syntax elementbased on the determined context, the one or more processors areconfigured to output a bitstream of encoded video data comprising thesecond syntax element.
 22. The device of claim 12, wherein the devicecomprises a video decoder, and wherein to code the second syntax elementbased on the determined context, the one or more processors areconfigured to receive a bitstream of encoded video data comprising thesecond syntax element and to determine the value for the second syntaxelement.